As computer platforms (e.g., operating systems) evolve from version to version, changes are made to support new technology, to provide “bug” fixes for known problems, and to implement modifications in design strategy. However, changes to the implementation of underlying functions relied upon to support execution of applications may result in application compatibility problems. For example, potential conflicts and/or inconsistencies might arise when attempting to execute old versions of an application on a newer platform that implements a function with a behavior different than that provided when a prior version of the platform implemented the same function.
Several methods exist for mitigating application compatibility issues. For example, in a method called shimming, applications that do not work properly with a new platform are identified, and a workaround fix is generated for the specific application that was identified as broken. Shim fixes implement a form of application program interface (API) hooking, and they are implemented as alternative code that executes upon redirection of an API call from the normal execution of operations in the platform. Shim code is housed outside of the platform core, and is maintained separately. Essentially, shimming injects additional code into the application before it interfaces with operations running in the platform.
Shimming is a tool to allow software written by third party software vendors to work with new platforms. However, shimming has some noted limitations with regard to fixing application compatibility. For example, because shimming executes in user-mode, shim code cannot be written to fix compatibility issues with kernel-mode code, such as interfaces of the application with device drivers, or other code that runs in kernel mode (e.g., some anti-virus, firewall, and anti-spyware code). Additionally, fixing compatibility issues for all applications executing on a platform with shim code is difficult, because the developer writing the shim code may not be aware of all applications being executed on the platform. Also, because shim code must be written for each application that is identified as incompatible, the shimming infrastructure suffers from a scalability standpoint.
Another method used to address application compatibility is versioning. In versioning, “broken components” are identified, and a component that keeps the old behaviors of old platform is created in the new platform. In places where the application can use the functionality of new components of the new platform, explicit links are made between the application code and the supporting components in the new platform. However, like shimming, versioning also suffers from scalability problems, as each place in the application code where links between the application code and new platform component functionality might exist must be identified and created.
Yet another method of supporting application compatibility is virtualization. In virtualization, the old platform and the new platform are run side-by side. In this way, applications that rely on old behaviors of the old platform may run using the old platform, while applications that have incorporated features to use aspects of the new platform are able to take advantage of those aspects. Virtualization however, is not void of difficulties when it comes to application compatibility. For example, integration and sensing of which applications should run on which platform, as well as how to share information between the virtual environment and the native environment may not be straightforward. Additionally, systems that employ virtualization necessarily must update and maintain both platforms, which can sometimes lead to conflicts when upgrading and/or updating the platforms using software patches (e.g., security updates).